This migration adds a new GiST index on (location::geometry), but the baseline schema already has a GiST index on listings.location ("listings_geo_index"). Unless you still need both geography and geometry indexes for different query patterns, keeping both will add write amplification and extra storage. Consider dropping the unused one (or replacing the existing index) so only the index that matches your spatial operators remains.

You introduced getListingCoordinates() to centralize coordinate access, but initialViewState still reads selectedListing.coordinates.* directly. For consistency (and to reduce the chance of a future shape change missing one call site), consider using getListingCoordinates(selectedListing) here as well (or destructure once and reuse).

The one-time useEffect that does initial positioning reads selectedListing/initialCoordinates, but it has an empty dependency array. If selectedListing is loaded asynchronously after mount (common when resolving the URL slug), this block won’t re-run, so the map may never center on the selected listing. Consider adding a dedicated useEffect that watches selectedListing?.coordinates (and a “has centered yet” ref/state) and calls flyTo once when the first valid selected listing becomes available, or move this behavior into the selectedListing-change path explicitly.

isFirstLoad.current is only set to false when the "IP coordinates" flyTo runs. If the page loads with a selected listing (URL param) you never clear isFirstLoad, so later when the user clears selectedListing this effect can fire and unexpectedly recenter the map to initialCoordinates. Consider setting isFirstLoad.current = false unconditionally after the first mount/map load, and gating the initialCoordinates centering with a separate ref that only tracks whether the initialCoordinates centering has already run (rather than reusing isFirstLoad).

hasCenteredSelectedListingRef is never reset when selectedListing changes, so this effect will only auto-center for the first listing that becomes selected during the component’s lifetime. If the user navigates to a different listing via URL/history (or selectedListing changes to a different id), the map won’t recenter. Consider tracking the last centered listing id/slug and resetting the ref when that identifier changes, or make the guard conditional on matching the currently selected listing.

The initial-positioning effect returns early whenever selectedListing is truthy, even if it has no valid coordinates (e.g. a not-found listing sets { error: true, ... }). In that case the map never applies initialCoordinates (IP fallback) because flyTo is skipped and initialViewState won’t update after mount. Consider changing the guard to only block when hasValidCoordinates(selectedListing) (or when a listing has already been centered), so invalid/errored selections still fall back to initialCoordinates.